Copyright: ID Copyright © 1995 Bjørn Mork


Contents
ID

The Ultimate Identification

and Finger server

Overview

Main window

Customising FINGER.TXT

Testing identification

About the protocols

Registration

Sections of the initialisation file

Command line options

Questions and answers

File list

Contacting the author

Legal stuff

Changes in this version


Main window

Most options in ID can be configured through the main window.

Some advanced options can be only changed by editing FINGER.TXT and ID.INI.


Turn on this option to get a pling every time a client connects to your machine. The sound is the normal system beep, so you won't hear anything if you have turned this beep off (Sound settings in Control Panel).


Log the full name of connecting machines, not only IP-address. This will place unnecessary extra load on your network connection, and may crash ID if you receive many requests at the same time.

Already resolved names will still be displayed, even if you turn this option off.

If you want to clear the internal name cache, exit and restart ID.

See also the section about ID and DNS


Log all messages to a file. Please see the section about logging to file.

NOTE: Only information logged after you turn on Log to file will be written to the file. Information already in the log window will not be.


Select a user name for identification services, and finger requests. You should use a name that makes sense to others. You should not use 8 bit characters (like the Norwegian æ,ø and å), or special characters. In particular, you should not use '$' in your user name.

See also Selecting a user name


Fill in your full name. If you've got a '$' in it, you should consider changing name :-)


Push this button for help. You already have, haven't you?


Information about ID. Not very useful, I admit. You get more and better information from this help file.


Exits the program. You can also use the ordinary Windows method, either selecting 'Close' from the system menu, or push Alt+F4 when the ID window is active.

There is no 'Do you really wanna quit? Are you completely sure? Etc..' box. ID may be started minimised from your start-up folder, and automatically closed at Windows exit, without you having to push any button.


All information is logged in this window. You can not turn off this logging. If you turn on Log to file, the same information will be written to ID.LOG in your ID directory.

If the log window is too small, and you want to see the full line length, turn on Log to file, and use a text editor to view the log file afterwards.


Customising FINGER.TXT

The FINGER.TXT file is a template for the verbose response to a finger request. It contains mostly plain text, and may be edited by an ordinary text editor like NOTEPAD. (Some editors will not work correct, see below.)

If the client doesn't use the 'verbose' flag, or requests information about all users, FINGER.TXT will not be used. Instead ID will return a standard short listing like this:

Login       Name                  Tty      Idle  Login Time

bjm         Bjørn Mork            console  -     Oct 17 09:07:23

Example request for verbose information from a UNIX machine to a Windows machine running ID (with this particular finger client, verbose response is turned on with the -l flag):

test on sparc114:42: finger -l bjm@128.1.1.145

[128.1.1.145]

Login name: bjm                         In real life: Bjørn Mork

Directory: C:\W31                       Shell: MSDOS version 6.20

On since Oct 17 09:07:23 on console

No project.

No plan.

The FINGER.TXT file was the default one, which looks like this:

Login name: $u                          In real life: $f

Directory: $d                           Shell: $o    version $v

On since $t              on console

No project.

No plan.

As you can see, most of the text is sent just like it appears in the local FINGER.TXT file. But there are a few variables (all starting with '$'), which expands to some text. All the possible variables appear in the default file above, and the meaning should be clear if you compare the file and the response. Here is a list of variables and a short description:

$u	The user name as it appears in the main ID window
$f	The full name of the user as it appears in the main ID window
$d	Your Windows directory
$o	Your operating system. This can only have two values: MSDOS or OS/2. These are the valid systems name for a computer running Windows, according to the current Internet assigned numbers RFC.
$v	Operating system version
$t	The time you started your Windows session. NOTE: Not the time you connected to the net, nor the time ID was started.

If you are writing your own FINGER.TXT, please note:

FINGER.TXT may be larger, but only the first 1024 characters, including inserted variables, will be sent to the client.

All variable names must be lowercase.

ID does not insert the variables, except when the variables are placed at the end of a line. Otherwise, ID will write the variable over any text at the same position in FINGER.TXT. You should therefore leave enough space after a variable. You can not use a text editor which replaces spaces with tabs, since ID will count a tab as one character. The standard Windows notepad is not useful for anything else, but it does fulfil these requirements.


I use FINGER.TXT throughout this example, but you may of course have changed the name of this file by editing ID.INI.


Testing Identification

The main problem when testing identification, is to find somebody who will test it for you. There is no Windows client, so you can't test it yourself. (In fact, there are no separate identification clients at all. Identification is just used as part of the connection to a server, e.g. a FTP server)

There are several servers of different kinds, which will use ID during the connection phase. I have come across IRC-servers, FTP-servers, NNTP(news, USENET)-servers, SMTP(mail)-servers, and WWW-servers which all have made identification requests.

The IRC-server is a special case: They actually based the access on whether the ID request was answered or not. This is not recommended, since you are free to respond with anything you want from a personal computer. (This goes for any computer, provided you have the privileges to run a server.)

The FTP-server used the information to present a nice login text:

220-Hello bmork at fp6-ppp3.oslo.net,

220-

220-Welcome to the FUNET archive,  Please login as `anonymous' with

220-your E-mail address as the password to access the archive.

220-See the README file for more information about this archive.

The answer probably got into the FTP-log, also. If you want to try this server, the address is ftp.funet.fi

I don't know what the NNTP-server uses the information for. Probably logging. My Internet service provider (ISP) requests identification information every time I connect to their news-server. I guess the information may prove useful if I have problems with their news-server. I can say: "Hey, every connection I've made is logged with 'bmork'." Since I have a dynamically assigned machine name, it would be virtually impossible to know who was connected when, without this extra ID.

My ISP also connects to the ID port when I send mail (SMTP) through their mail relay. The collected information is probably logged. In addition, it shows up in the mail headers. A very nice feature, indeed! Mail with ID looks like this:

Return-Path: bmork@sn.no

Received: from pcbjorn (bmork@fp2-ppp15.oslo.net [194.143.3.48]) by hasle.oslonett.no (8.6.12/on1) with SMTP id <CAA14216> for <bmork@sn.no>; Sun, 15 Oct 1995 02:29:53 +0100

and without ID:

Return-Path: bmork@sn.no

Received: from pcbjorn (fp2-ppp15.oslo.net [194.143.3.48]) by hasle.oslonett.no (8.6.12/on1) with SMTP id <CAA13804> for <bmork@sn.no>; Sun, 15 Oct 1995 02:23:50 +0100

Notice the Received from header.

The WWW-servers probably use the information for logging. An identification server may be used to log unique accesses when different users access the server from the same machine. (Remember: If you have a dynamic address, other people will use the same machine name as you, even if you are alone).

WWW-servers are nice for testing purposes, as they place a heavy load on ID (They will check your ID for every file you retrieve, including pictures...). If you want to try: Here are some servers which checked ID when I wrote this:

	www.texas.net (but www2.texas,net will not check ID)
	www.stud.unit.no
	www.mediavis.com


About the Protocols

ID is both a finger and an identification server. The finger protocol is described in RFC1288. The identification protocol is described in RFC1413.

The identification protocol was formerly called 'the authentication server protocol'. You may see this term still used. The name of the service is still 'auth'.


Overview

ID is an identification server (or daemon, if you prefer) for Windows 3.x. It is also a finger  server, but this is considered (by the author, me) to be a secondary function. There are several finger daemons available; many of them with much better functionality. Look for them in the winsock directory at CICA (now ftp.winsite.com). The finger server was included in ID because much of the same code could be used. Both servers take one line of input and give a short answer including a user name. This is also one of the reasons why the finger server is so simple: I did not want to add much extra code. If you require the finger server to answer requests for more than one user, or send more than 1024 characters in the answer, you should look for another program than ID.


Registration

ID is released as freeware. There is no need to register.

However, if you want to let me know that you are using this program, send me a mail.


Initialisation
id.ini

If the placement of ID.INI has not been overridden (see Command line options), and there is no ID.INI file in the ID directory, ID will create one in this directory. You can configure ID by editing the ID.INI file, but this is usually not necessary. You should not edit ID.INI while ID is running, as ID will write all options stored in memory to ID.INI on exit.

ID.INI has only one section, [ID], with the following optional entries:

Username

The user name you have selected.

Fullname

Your full name

Logfile

The location of the file for logging information. Default: ID.LOG in the ID directory.

Fingerfile

The location of the finger template. Can only be changed by editing ID.INI. Default: FINGER.TXT in ID directory.

Sound

1 if ID should use sound, 0 if not. Default: 1

Resolve

1 if ID should use resolve client names, 0 if not. Default: 1

Log to file

1 if ID should log all messages to a file, 0 if not. Default: 0

Start Minimised

1 if ID should start minimised. Useful when running from a script. Default: 0

Timeout

The time in seconds ID will wait for data before closing a dead connection. Default: 60

NoFinger

Set to 1 if you don't want ID to run the finger server. Default: 0

NoIdent

Set to 1 if you don't want ID to run the identification server. Default: 0

NOTE: ID will not run if both NoFinger and NoIdent is set to 1.


Only configurable through editing ID.INI. You may have to add this entry to ID.INI.


Command line
Command Line Options

ID currently only recognises one command line option: The name and location of ID.INI. If this is given, it must include the full path name of the file. The filename does not need to be ID.INI.

Syntax:

ID.EXE -inipath=<FILEPATH>

Example:

ID.EXE -inipath=D:\MYDIR\MYNAME.INI


Questions and Answers

By now you're probably wondering:

Q: "What is an identification server, anyway?"

Q: "What can I use it for?"

Q: "Why do I need ID?"

Q: "What programs (clients) are there for ID servers?"

Q: "How does it work?"

Q: "What is my user name?"

Q: "Why is the service name 'auth', and not 'ident'"?

Q: "Where can I get more information about the identification protocol?"

Q: "How do I run another finger server, and still keep ID for identification?"

Q: "Where can I get the latest version of ID"


It's a way of letting other people know who they are dealing with. When you connect to another machine, the other machine will ask your machine "Who owns this connection?".


It's not for you to use. You will run ID as a service to others. "Others" is almost always other machines. People don't use identification servers, they use finger instead.


You don't. You have had no problems without one (maybe except for some IRC-servers). But I recommend that you try ID for a while. Use the sound option to find out when a request is being made, or watch the log. You will probably be as surprised as I was over how many requests there are on a normal day.


None. That is: None for use by humans. Humans will use a finger client if they want information about a particular user, or machine.


A client connects to the (virtual TCP) port 113, which is the "auth" port. It then requests the name of the owner of an active connection by sending a pair of ports identifying the connection. The identification server (ID) answers with the port pair, operating system, and user name of the connection owner. The format of the latter is not specified, but depends on the operating system.


This depends on the system you are running. In Windows 3.x, you don't have one. But for the purpose of identification and finger requests, you should choose one. This name should have the same restrictions as an ordinary UNIX user name. Remember that this information is usually meant for machines, not humans. The information should generally be useful to the receiver. You do most likely have a user name on another system, e.g. with your Internet service provider. Choosing the same login name on every system, including your local computer, is generally a good idea.


The identification protocol was previously known as 'the authentication protocol'. This was misleading, since the protocol has nothing to do with security, therefore the change of name. The name of the service cannot easily be changed, and will probably always be "auth". This is because the service name is hardcoded into software.


Read RFC1413


If you want to run another finger server instead of ID, just start the other server first. ID will give an error message. Ignore this message. ID will still function as an identification server.


The latest version can be found through my homepage <URL:http://www.sn.no/~bmork/>. ID is also uploaded to ftp.winsite.com


Files
List of files

Please refer to README.TXT for a complete listing of files included in the archive, and the latest updates to this information.

id.exe¹

id.hlp¹

id.ini

ctl3d.dll¹

id.log

finger.txt¹

readme.txt¹

services

¹ Included in the archive. The other files are already present on your computer as part of other program packages, or created after installation.


Contacting the Author

The author can be contacted (preferably) by email to:

bmork@sn.no

or by mail:

Bjørn Mork

Knut Alvssons vei 5

N-0574 Oslo

Norway

Bug reports and applause is welcome :-)

See also my home page for the latest news about ID:

<URL:http://www.sn.no/~bmork/>


id.exe

This is the main server program. The program uses a Dynamic Link Library (DLL), which is a library that are shared with other Windows programs. If the program won't start at all, you may be missing this file:

CTL3D.DLL	Microsoft 3D Custom Controls


id.hlp

This is of course the help file you're reading right now. I guess you've got it :-)


ctl3d.dll

Microsoft 3D Custom Controls. Adds 3D look to dialogue boxes, and also to the main window of ID. ID will not run without this library present. The location for this file should be your Windows system directory (often C:\WINDOWS\SYSTEM, but may be different on your computer).

Most people don't have to worry about this file at all, because it is already installed by other programs.


Logging to file

The ID.LOG file is created in your ID directory if you choose to log to file. If the file already exists, it is appended.

All the information in the log window will be written to this file. This includes:

	Start-up message with information about the WINSOCK.DLL
	Error messages
	Connections from clients (with name if you have chosen to resolve these)
	Shutdown time

The information is logged continuously, but the file is closed between each message logged.

This does of course create some overhead compared to keeping the file open, or better, to flush the log window to file at the end of a session. I did not want to do this because ID is early in development. Although somewhat tested, and fairly stable, it may crash. The information contained in a log file is then very important, but would be lost by choosing one of the faster techniques.

The number of entries in a log file is normally not very high. But the file will continue to grow until you delete it, so you'd better watch out!


readme.txt

This file contains last minute information, and a list of known bugs.


services

The 'services' file is part of your TCP/IP stack. This file contains the mapping from a service name to a port/protocol pair. ID uses these two entries:

finger          79/tcp

auth            113/tcp         authentication


Legal stuff

The formalities in a simple, readable form (for those of you who are concerned about legal stuff):

1.	This program is free. It is illegal to sell this program.

2.	This program is freely redistributable. You may distribute this program in any form, and on any type of media. Although selling the program is forbidden, you may charge a reasonable fee to cover distribution costs.

3.	This program comes with no warranty whatsoever. You get what you pay for. See also no.1.


Selecting a user name

In principle, the user name may be any text you want.

But, if the name doesn't make sense to others, there is really no use running ID at all. So, you have to be careful. ID does not support selecting character sets as suggested by RFC1413, the only set supported is the default (7bit US-ASCII). This is not because I didn't want to include this support (remember: I need ISO-8859-1 to write my name...), but because none of the clients I tested understood it (or wanted to use the data).

If you have read the section about customising FINGER.TXT, you do probably understand why you should not include '$' in your user name. If the '$' and the next character forms one of the variables, ID will expand it recursively. ID will still stop the transfer when the 1024 character limit is reached, so this will not crash anything. But the response will look rather ugly.

Some very strict clients may expect the user name to consist of only lower case letters 'a' to 'z' and numbers '0' to '9'. If you want your ID to be recognised by all clients, you should use only these characters.

You probably have an email address on the form username@providers.machine. I recommend using the same username. Since this name is a valid user name on one system, it should be a valid ID for any system. This is the most meaningful response a client can expect.

Another possibility is to use your complete mail address as user name. This may be confusing to some programs, but should make very much sense to a system administrator going through a log.

ID currently limits the user name to 32 characters.


ID and DNS

The identification protocol is supposed to be a very fast identity check. There should not be any noticeable connection delay due to this check. Therefore, ID can not wait for the name of the client to be resolved.

The current version of ID does not use asynchronous DNS. This ensure compatibility with most Winsock 1.1 TCP/IP stacks. The synchronous DNS will halt the current execution thread, while waiting for a name to be resolved.

To avoid delays in identification, ID will first answer the request and close the connection, and then try to resolve the clients name. This may cause a delay between the 'beep' and the message in the log window, since ID beeps on connect, but have to wait for DNS before logging the connection.

Until I met the web-server at www.stud.unit.no, I thought this was an OK procedure. But when I suddenly received more than ten identification requests from the same machine at the same time, I realised that something had to be done.

The solution was to cache the names as they were resolved. One host name entry only needs a few tens of bytes, while the cost of resolving a name is high, both in time and network traffic.

ID will now cache all resolved host names as long as it is running. Theoretically, this may lead to problems if ID runs for a very long time. But in practical use, I don't think it matters. You have to receive requests from a very large number of different hosts to run out of memory. Since there is no ageing mechanism, you may get the wrong name if someone was to change his host name while ID is running. But who cares? This name is only used for logging purposes, and the IP-address will always be there.

A feature that may be somewhat confusing: If you turn off 'Resolve client names', ID will still use all names already in the cache. Only unknown hosts will not be resolved.


RFC1288

Network Working Group                                       D. Zimmerman

Request for Comments: 1288           Center for Discrete Mathematics and

Obsoletes: RFCs 1196, 1194, 742             Theoretical Computer Science

                                                           December 1991

                  The Finger User Information Protocol

Status of this Memo

   This memo defines a protocol for the exchange of user information.

   This RFC specifies an IAB standards track protocol for the Internet

   community, and requests discussion and suggestions for improvements.

   Please refer to the current edition of the "IAB Official Protocol

   Standards" for the standardization state and status of this protocol.

   Distribution of this memo is unlimited.

Abstract

   This memo describes the Finger user information protocol.  This is a

   simple protocol which provides an interface to a remote user

   information program.

   Based on RFC 742, a description of the original Finger protocol, this

   memo attempts to clarify the expected communication between the two

   ends of a Finger connection.  It also tries not to invalidate the

   many existing implementations or add unnecessary restrictions to the

   original protocol definition.

   This edition corrects and clarifies RFC 1196.

   Table of Contents

   1.      Introduction  ...........................................   2

     1.1.    Intent  ...............................................   2

     1.2.    History  ..............................................   3

     1.3.    Requirements  .........................................   3

     1.4.    Updates  ..............................................   3

   2.      Use of the protocol  ....................................   4

     2.1.    Flow of events  .......................................   4

     2.2.    Data format  ..........................................   4

     2.3.    Query specifications  .................................   4

     2.4.    RUIP {Q2} behavior  ...................................   5

     2.5.    Expected RUIP response  ...............................   6

       2.5.1.  {C} query  ..........................................   6

       2.5.2.  {U}{C} query  .......................................   6

       2.5.3.  {U} ambiguity  ......................................   7

       2.5.4.  /W query token  .....................................   7

       2.5.5.  Vending machines  ...................................   7

   3.      Security  ...............................................   7

     3.1.    Implementation security  ..............................   7

     3.2.    RUIP security  ........................................   8

       3.2.1.  {Q2} refusal  .......................................   8

       3.2.2.  {C} refusal  ........................................   8

       3.2.3.  Atomic discharge  ...................................   8

       3.2.4.  User information files  .............................   9

       3.2.5.  Execution of user programs  .........................   9

       3.2.6.  {U} ambiguity  ......................................   9

       3.2.7.  Audit trails  .......................................   9

     3.3.    Client security  ......................................   9

   4.      Examples  ...............................................  10

     4.1.    Example with a null command line ({C})  ...............  10

     4.2.    Example with name specified ({U}{C})  .................  10

     4.3.    Example with ambiguous name specified ({U}{C})  .......  11

     4.4.    Example of query type {Q2} ({U}{H}{H}{C})  ............  11

   5.      Acknowledgments  ........................................  12

   6.      Security Considerations  ................................  12

   7.      Author's Address  .......................................  12

1.  Introduction

1.1.  Intent

   This memo describes the Finger user information protocol.  This is a

   simple protocol which provides an interface to a remote user

   information program (RUIP).

   Based on RFC 742, a description of the original Finger protocol, this

   memo attempts to clarify the expected communication between the two

   ends of a Finger connection.  It also tries not to invalidate the

   many current implementations or add unnecessary restrictions to the

   original protocol definition.

   The most prevalent implementations of Finger today seem to be

   primarily derived from the BSD UNIX work at the University of

   California, Berkeley.  Thus, this memo is based around the BSD

   version's behavior.

   However, the BSD version provides few options to tailor the Finger

   RUIP for a particular site's security policy, or to protect the user

   from dangerous data.  Furthermore, there are MANY potential security

   holes that implementors and administrators need to be aware of,

   particularly since the purpose of this protocol is to return

   information about a system's users, a sensitive issue at best.

   Therefore, this memo makes a number of important security comments

   and recommendations.

1.2.  History

   The FINGER program at SAIL, written by Les Earnest, was the

   inspiration for the NAME program on ITS.  Earl Killian at MIT and

   Brian Harvey at SAIL were jointly responsible for implementing the

   original protocol.

   Ken Harrenstien is the author of RFC 742, "Name/Finger", which this

   memo began life as.

1.3.  Requirements

   In this document, the words that are used to define the significance

   of each particular requirement are capitalized.  These words are:

   * "MUST"

      This word or the adjective "REQUIRED" means that the item is an

      absolute requirement of the specification.

   * "SHOULD"

      This word or the adjective "RECOMMENDED" means that there may

      exist valid reasons in particular circumstances to ignore this

      item, but the full implications should be understood and the case

      carefully weighed before choosing a different course.

   * "MAY"

      This word or the adjective "OPTIONAL" means that this item is

      truly optional.  One vendor may choose to include the item because

      a particular marketplace requires it or because it enhances the

      product, for example; another vendor may omit the same item.

   An implementation is not compliant if it fails to satisfy one or more

   of the MUST requirements.  An implementation that satisfies all the

   MUST and all the SHOULD requirements is said to be "unconditionally

   compliant"; one that satisfies all the MUST requirements but not all

   the SHOULD requirements is said to be "conditionally compliant".

1.4.  Updates

   The differences of note between RFC 1196 and this memo are:

      o the optional /W switch in the Finger query specification was

        mistakenly placed at the end of the line.  The 4.3BSD Finger

        specifies it at the beginning, where this memo now also puts

        it.

      o the BNF in the Finger query specification was not clear on the

        treatment of blank space.  This memo is more exacting by

        including an explicit token for it.

      o The flow of events in a Finger connection is now better

        defined on the topic of the close of the Finger connection.

2.  Use of the protocol

2.1.  Flow of events

   Finger is based on the Transmission Control Protocol, using TCP port

   79 decimal (117 octal).  The local host opens a TCP connection to a

   remote host on the Finger port.  An RUIP becomes available on the

   remote end of the connection to process the request.  The local host

   sends the RUIP a one line query based upon the Finger query

   specification, and waits for the RUIP to respond.  The RUIP receives

   and processes the query, returns an answer, then initiates the close

   of the connection.  The local host receives the answer and the close

   signal, then proceeds closing its end of the connection.

2.2.  Data format

   Any data transferred MUST be in ASCII format, with no parity, and

   with lines ending in CRLF (ASCII 13 followed by ASCII 10).  This

   excludes other character formats such as EBCDIC, etc.  This also

   means that any characters between ASCII 128 and ASCII 255 should

   truly be international data, not 7-bit ASCII with the parity bit set.

2.3.  Query specifications

   An RUIP MUST accept the entire Finger query specification.

   The Finger query specification is defined:

        {Q1}    ::= [{W}|{W}{S}{U}]{C}

        {Q2}    ::= [{W}{S}][{U}]{H}{C}

        {U}     ::= username

        {H}     ::= @hostname | @hostname{H}

        {W}     ::= /W

        {S}     ::= <SP> | <SP>{S}

        {C}     ::= <CRLF>

   {H}, being recursive, means that there is no arbitrary limit on the

   number of @hostname tokens in the query.  In examples of the {Q2}

   request specification, the number of @hostname tokens is limited to

   two, simply for brevity.

   Be aware that {Q1} and {Q2} do not refer to a user typing "finger

   user@host" from an operating system prompt.  It refers to the line

   that an RUIP actually receives.  So, if a user types "finger

   user@host<CRLF>", the RUIP on the remote host receives "user<CRLF>",

   which corresponds to {Q1}.

   As with anything in the IP protocol suite, "be liberal in what you

   accept".

2.4.  RUIP {Q2} behavior

   A query of {Q2} is a request to forward a query to another RUIP.  An

   RUIP MUST either provide or actively refuse this forwarding service

   (see section 3.2.1).  If an RUIP provides this service, it MUST

   conform to the following behavior:

   Given that:

         Host <H1> opens a Finger connection <F1-2> to an RUIP on host

         <H2>.

         <H1> gives the <H2> RUIP a query <Q1-2> of type {Q2}

         (e.g., FOO@HOST1@HOST2).

   It should be derived that:

         Host <H3> is the right-most host in <Q1-2> (i.e., HOST2)

         Query <Q2-3> is the remainder of <Q1-2> after removing the

         right-most "@hostname" token in the query (i.e., FOO@HOST1)

   And so:

         The <H2> RUIP then must itself open a Finger connection <F2-3>

         to <H3>, using <Q2-3>.

         The <H2> RUIP must return any information received from <F2-3>

         to <H1> via <F1-2>.

         The <H2> RUIP must close <F1-2> in normal circumstances only

         when the <H3> RUIP closes <F2-3>.

2.5.  Expected RUIP response

   For the most part, the output of an RUIP doesn't follow a strict

   specification, since it is designed to be read by people instead of

   programs.  It should mainly strive to be informative.

   Output of ANY query is subject to the discussion in the security

   section.

2.5.1.  {C} query

   A query of {C} is a request for a list of all online users.  An RUIP

   MUST either answer or actively refuse (see section 3.2.2).  If it

   answers, then it MUST provide at least the user's full name.  The

   system administrator SHOULD be allowed to include other useful

   information (per section 3.2.3), such as:

      -    terminal location

      -    office location

      -    office phone number

      -    job name

      -    idle time (number of minutes since last typed input, or

           since last job activity).

2.5.2.  {U}{C} query

   A query of {U}{C} is a request for in-depth status of a specified

   user {U}.  If you really want to refuse this service, you probably

   don't want to be running Finger in the first place.

   An answer MUST include at least the full name of the user.  If the

   user is logged in, at least the same amount of information returned

   by {C} for that user MUST also be returned by {U}{C}.

   Since this is a query for information on a specific user, the system

   administrator SHOULD be allowed to choose to return additional useful

   information (per section 3.2.3), such as:

            -    office location

            -    office phone number

            -    home phone number

            -    status of login (not logged in, logout time, etc)

            -    user information file

   A user information file is a feature wherein a user may leave a short

   message that will be included in the response to Finger requests.

   (This is sometimes called a "plan" file.)  This is easily implemented

   by (for example) having the program look for a specially named text

   file in the user's home directory or some common area; the exact

   method is left to the implementor.  The system administrator SHOULD

   be allowed to specifically turn this feature on and off.  See section

   3.2.4 for caveats.

   There MAY be a way for the user to run a program in response to a

   Finger query.  If this feature exists, the system administrator

   SHOULD be allowed to specifically turn it on and off.  See section

   3.2.5 for caveats.

2.5.3.  {U} ambiguity

   Allowable "names" in the command line MUST include "user names" or

   "login names" as defined by the system.  If a name is ambiguous, the

   system administrator SHOULD be allowed to choose whether or not all

   possible derivations should be returned in some fashion (per section

   3.2.6).

2.5.4.  /W query token

   The token /W in the {Q1} or {Q2} query types SHOULD at best be

   interpreted at the last RUIP to signify a higher level of verbosity

   in the user information output, or at worst be ignored.

2.5.5.  Vending machines

   Vending machines SHOULD respond to a {C} request with a list of all

   items currently available for purchase and possible consumption.

   Vending machines SHOULD respond to a {U}{C} request with a detailed

   count or list of the particular product or product slot.  Vending

   machines should NEVER NEVER EVER eat money.

3.  Security

3.1.  Implementation security

   Sound implementation of Finger is of the utmost importance.

   Implementations should be tested against various forms of attack.  In

   particular, an RUIP SHOULD protect itself against malformed inputs.

   Vendors providing Finger with the operating system or network

   software should subject their implementations to penetration testing.

   Finger is one of the avenues for direct penetration, as the Morris

   worm pointed out quite vividly.  Like Telnet, FTP and SMTP, Finger is

   one of the protocols at the security perimeter of a host.

   Accordingly, the soundness of the implementation is paramount.  The

   implementation should receive just as much security scrutiny during

   design, implementation, and testing as Telnet, FTP, or SMTP.

3.2.  RUIP security

   Warning!!  Finger discloses information about users; moreover, such

   information may be considered sensitive.  Security administrators

   should make explicit decisions about whether to run Finger and what

   information should be provided in responses.  One existing

   implementation provides the time the user last logged in, the time he

   last read mail, whether unread mail was waiting for him, and who the

   most recent unread mail was from!  This makes it possible to track

   conversations in progress and see where someone's attention was

   focused.  Sites that are information-security conscious should not

   run Finger without an explicit understanding of how much information

   it is giving away.

3.2.1.  {Q2} refusal

   For individual site security concerns, the system administrator

   SHOULD be given an option to individually turn on or off RUIP

   processing of {Q2}.  If RUIP processing of {Q2} is turned off, the

   RUIP MUST return a service refusal message of some sort.  "Finger

   forwarding service denied" is adequate.  The purpose of this is to

   allow individual hosts to choose to not forward Finger requests, but

   if they do choose to, to do so consistently.

   Overall, there are few cases which would warrant processing of {Q2}

   at all, and they are far outweighed by the number of cases for

   refusing to process {Q2}.  In particular, be aware that if a machine

   is part of security perimeter (that is, it is a gateway from the

   outside world to some set of interior machines), then turning {Q2} on

   provides a path through that security perimeter.  Therefore, it is

   RECOMMENDED that the default of the {Q2} processing option be to

   refuse processing.  It certainly should not be enabled in gateway

   machines without careful consideration of the security implications.

3.2.2.  {C} refusal

   For individual site security concerns, the system administrator

   SHOULD be given an option to individually turn on or off RUIP

   acceptance of {C}.  If RUIP processing of {C} is turned off, the RUIP

   MUST return a service refusal message of some sort.  "Finger online

   user list denied" is adequate.  The purpose of this is to allow

   individual hosts to choose to not list the users currently online.

3.2.3.  Atomic discharge

   All implementations of Finger SHOULD allow individual system

   administrators to tailor what atoms of information are returned to a

   query.  For example:

      -    Administrator A should be allowed to specifically choose to

           return office location, office phone number, home phone

           number, and logged in/logout time.

      -    Administrator B should be allowed to specifically choose to

           return only office location, and office phone number.

      -    Administrator C should be allowed to specifically choose to

           return the minimum amount of required information, which is

           the person's full name.

3.2.4.  User information files

   Allowing an RUIP to return information out of a user-modifiable file

   should be seen as equivalent to allowing any information about your

   system to be freely distributed.  That is, it is potentially the same

   as turning on all specifiable options.  This information security

   breach can be done in a number of ways, some cleverly, others

   straightforwardly.  This should disturb the sleep of system

   administrators who wish to control the returned information.

3.2.5.  Execution of user programs

   Allowing an RUIP to run a user program in response to a Finger query

   is potentially dangerous.  BE CAREFUL!! -- the RUIP MUST NOT allow

   system security to be compromised by that program.  Implementing this

   feature may be more trouble than it is worth, since there are always

   bugs in operating systems, which could be exploited via this type of

   mechanism.

3.2.6.  {U} ambiguity

   Be aware that a malicious user's clever and/or persistent use of this

   feature can result in a list of most of the usernames on a system.

   Refusal of {U} ambiguity should be considered in the same vein as

   refusal of {C} requests (see section 3.2.2).

3.2.7.  Audit trails

   Implementations SHOULD allow system administrators to log Finger

   queries.

3.3.  Client security

   It is expected that there will normally be some client program that

   the user runs to query the initial RUIP.  By default, this program

   SHOULD filter any unprintable data, leaving only printable 7-bit

   characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs.

   This is to protect against people playing with terminal escape codes,

   changing other peoples' X window names, or committing other dastardly

   or confusing deeds.  Two separate user options SHOULD be considered

   to modify this behavior, so that users may choose to view

   international or control characters:

      -    one to allow all characters less than ASCII 32

      -    another to allow all characters greater than ASCII 126

   For environments that live and breathe international data, the system

   administrator SHOULD be given a mechanism to enable the latter option

   by default for all users on a particular system.  This can be done

   via a global environment variable or similar mechanism.

4.  Examples

4.1.  Example with a null command line ({C})

Site: elbereth.rutgers.edu

Command line: <CRLF>

Login       Name               TTY Idle    When            Office

rinehart Mark J. Rinehart      p0  1:11 Mon 12:15  019 Hill       x3166

greenfie Stephen J. Greenfiel  p1       Mon 15:46  542 Hill       x3074

rapatel  Rocky - Rakesh Patel  p3    4d Thu 00:58  028 Hill       x2287

pleasant Mel Pleasant          p4    3d Thu 21:32  019 Hill    908-932-

dphillip Dave Phillips         p5  021: Sun 18:24  265 Hill       x3792

dmk      David Katinsky        p6    2d Thu 14:11  028 Hill       x2492

cherniss Cary Cherniss         p7    5  Mon 15:42  127 Psychol    x2008

harnaga  Doug Harnaga          p8  2:01 Mon 10:15  055 Hill       x2351

brisco   Thomas P. Brisco      pe  2:09 Mon 13:37  h055           x2351

laidlaw  Angus Laidlaw         q0  1:55 Mon 11:26  E313C       648-5592

cje      Chris Jarocha-Ernst   q1    8  Mon 13:43  259 Hill       x2413

4.2.  Example with name specified ({U}{C})

Site: dimacs.rutgers.edu

Command line: pirmann<CRLF>

Login name: pirmann                     In real life: David Pirmann

Office: 016 Hill, x2443                 Home phone: 989-8482

Directory: /dimacs/u1/pirmann           Shell: /bin/tcsh

Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.

No unread mail

Project:

Plan:

                      Work Schedule, Summer 1990

                 Rutgers LCSR Operations, 908-932-2443

                        Monday       5pm - 12am

                        Tuesday      5pm - 12am

                        Wednesday    9am -  5pm

                        Thursday     9am -  5pm

                        Saturday     9am -  5pm

                           larf larf hoo hoo

4.3.  Example with ambiguous name specified ({U}{C})

Site: elbereth.rutgers.edu

Command line: ron<CRLF>

Login name: spinner                     In real life: Ron Spinner

Office: Ops Cubby,    x2443             Home phone: 463-7358

Directory: /u1/spinner                  Shell: /bin/tcsh

Last login Mon May  7 16:38 on ttyq7

Plan:

            ught i

          ca      n

        m           a

       '      ...     t

      I      .   .     i

             !         m

      !       !       e

       p       !pool

        l

         e

          H

Login name: surak                       In real life: Ron Surak

Office: 000 OMB Dou,    x9256

Directory: /u2/surak                    Shell: /bin/tcsh

Last login Fri Jul 27 09:55 on ttyq3

No Plan.

Login name: etter                       In real life: Ron Etter

Directory: /u2/etter                    Shell: /bin/tcsh

Never logged in.

No Plan.

4.4.  Example of query type {Q2} ({U}{H}{H}{C})

Site: dimacs.rutgers.edu

Command line: hedrick@math.rutgers.edu@pilot.njin.net<CRLF>

[pilot.njin.net]

[math.rutgers.edu]

Login name: hedrick                     In real life: Charles Hedrick

Office: 484 Hill, x3088

Directory: /math/u2/hedrick             Shell: /bin/tcsh

Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge

No unread mail

No Plan.

5.  Acknowledgments

   Thanks to everyone in the Internet Engineering Task Force for their

   comments.  Special thanks to Steve Crocker for his security

   recommendations and prose.

6.  Security Considerations

   Security issues are discussed in Section 3.

7.  Author's Address

   David Paul Zimmerman

   Center for Discrete Mathematics and

   Theoretical Computer Science (DIMACS)

   Rutgers University

   P.O. Box 1179

   Piscataway, NJ 08855-1179

   Phone: (908)932-4592

   EMail: dpz@dimacs.rutgers.edu


RFC1413

Network Working Group                                       M. St. Johns

Request for Comments: 1413                      US Department of Defense

Obsoletes: 931                                             February 1993

                        Identification Protocol

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet

   community, and requests discussion and suggestions for improvements.

   Please refer to the current edition of the "IAB Official Protocol

   Standards" for the standardization state and status of this protocol.

   Distribution of this memo is unlimited.

1.  INTRODUCTION

   The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident

   Protocol") provides a means to determine the identity of a user of a

   particular TCP connection.  Given a TCP port number pair, it returns

   a character string which identifies the owner of that connection on

   the server's system.

   The Identification Protocol was formerly called the Authentication

   Server Protocol.  It has been renamed to better reflect its function.

   This document is a product of the TCP Client Identity Protocol

   Working Group of the Internet Engineering Task Force (IETF).

2.  OVERVIEW

   This is a connection based application on TCP.  A server listens for

   TCP connections on TCP port 113 (decimal).  Once a connection is

   established, the server reads a line of data which specifies the

   connection of interest.  If it exists, the system dependent user

   identifier of the connection of interest is sent as the reply.  The

   server may then either shut the connection down or it may continue to

   read/respond to multiple queries.

   The server should close the connection down after a configurable

   amount of time with no queries - a 60-180 second idle timeout is

   recommended.  The client may close the connection down at any time;

   however to allow for network delays the client should wait at least

   30 seconds (or longer) after a query before abandoning the query and

   closing the connection.

3.  RESTRICTIONS

   Queries are permitted only for fully specified connections.  The

   query contains the local/foreign port pair -- the local/foreign

   address pair used to fully specify the connection is taken from the

   local and foreign address of query connection.  This means a user on

   address A may only query the server on address B about connections

   between A and B.

4.  QUERY/RESPONSE FORMAT

   The server accepts simple text query requests of the form:

            <port-on-server> , <port-on-client>

   where <port-on-server> is the TCP port (decimal) on the target (where

   the "ident" server is running) system, and <port-on-client> is the

   TCP port (decimal) on the source (client) system.

   N.B - If a client on host A wants to ask a server on host B about a

   connection specified locally (on the client's machine) as 23, 6191

   (an inbound TELNET connection), the client must actually ask about

   6191, 23 - which is how the connection would be specified on host B.

      For example:

                 6191, 23

   The response is of the form

   <port-on-server> , <port-on-client> : <resp-type> : <add-info>

   where <port-on-server>,<port-on-client> are the same pair as the

   query, <resp-type> is a keyword identifying the type of response, and

   <add-info> is context dependent.

   The information returned is that associated with the fully specified

   TCP connection identified by <server-address>, <client-address>,

   <port-on-server>, <port-on-client>, where <server-address> and

   <client-address> are the local and foreign IP addresses of the

   querying connection -- i.e., the TCP connection to the Identification

   Protocol Server.  (<port-on-server> and <port-on-client> are taken

   from the query.)

      For example:

         6193, 23 : USERID : UNIX : stjohns

         6195, 23 : ERROR : NO-USER

5.  RESPONSE TYPES

A response can be one of two types:

USERID

     In this case, <add-info> is a string consisting of an

     operating system name (with an optional character set

     identifier), followed by ":", followed by an

     identification string.

     The character set (if present) is separated from the

     operating system name by ",".  The character set

     identifier is used to indicate the character set of the

     identification string.  The character set identifier,

     if omitted, defaults to "US-ASCII" (see below).

     Permitted operating system names and character set

     names are specified in RFC 1340, "Assigned Numbers" or

     its successors.

     In addition to those operating system and character set

     names specified in "Assigned Numbers" there is one

     special case operating system identifier - "OTHER".

     Unless "OTHER" is specified as the operating system

     type, the server is expected to return the "normal"

     user identification of the owner of this connection.

     "Normal" in this context may be taken to mean a string

     of characters which uniquely identifies the connection

     owner such as a user identifier assigned by the system

     administrator and used by such user as a mail

     identifier, or as the "user" part of a user/password

     pair used to gain access to system resources.  When an

     operating system is specified (e.g., anything but

     "OTHER"), the user identifier is expected to be in a

     more or less immediately useful form - e.g., something

     that could be used as an argument to "finger" or as a

     mail address.

     "OTHER" indicates the identifier is an unformatted

     character string consisting of printable characters in

     the specified character set.  "OTHER" should be

     specified if the user identifier does not meet the

     constraints of the previous paragraph.  Sending an

     encrypted audit token, or returning other non-userid

     information about a user (such as the real name and

     phone number of a user from a UNIX passwd file) are

     both examples of when "OTHER" should be used.

     Returned user identifiers are expected to be printable

     in the character set indicated.

     The identifier is an unformatted octet string - - all

     octets are permissible EXCEPT octal 000 (NUL), 012 (LF)

     and 015 (CR).  N.B. - space characters (040) following the

     colon separator ARE part of the identifier string and

     may not be ignored. A response string is still

     terminated normally by a CR/LF.  N.B. A string may be

     printable, but is not *necessarily* printable.

ERROR

   For some reason the port owner could not be determined, <add-info>

   tells why.  The following are the permitted values of <add-info> and

   their meanings:

          INVALID-PORT

          Either the local or foreign port was improperly

          specified.  This should be returned if either or

          both of the port ids were out of range (TCP port

          numbers are from 1-65535), negative integers, reals or

          in any fashion not recognized as a non-negative

          integer.

          NO-USER

          The connection specified by the port pair is not

          currently in use or currently not owned by an

          identifiable entity.

          HIDDEN-USER

          The server was able to identify the user of this

          port, but the information was not returned at the

          request of the user.

          UNKNOWN-ERROR

          Can't determine connection owner; reason unknown.

          Any error not covered above should return this

          error code value.  Optionally, this code MAY be

          returned in lieu of any other specific error code

          if, for example, the server desires to hide

          information implied by the return of that error

          code, or for any other reason.  If a server

          implements such a feature, it MUST be configurable

          and it MUST default to returning the proper error

          message.

   Other values may eventually be specified and defined in future

   revisions to this document.  If an implementer has a need to specify

   a non-standard error code, that code must begin with "X".

   In addition, the server is allowed to drop the query connection

   without responding.  Any premature close (i.e., one where the client

   does not receive the EOL, whether graceful or an abort should be

   considered to have the same meaning as "ERROR : UNKNOWN-ERROR".

FORMAL SYNTAX

   <request> ::= <port-pair> <EOL>

   <port-pair> ::= <integer> "," <integer>

   <reply> ::= <reply-text> <EOL>

   <EOL> ::= "015 012"  ; CR-LF End of Line Indicator

   <reply-text> ::= <error-reply> | <ident-reply>

   <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>

   <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>

                     ":" <user-id>

   <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"

                    | "HIDDEN-USER" |  <error-token>

   <opsys-field> ::= <opsys> [ "," <charset>]

   <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.

               ;  (See "Assigned Numbers")

   <charset> ::= "US-ASCII" | ...etc.

                 ;  (See "Assigned Numbers")

   <user-id> ::= <octet-string>

   <token> ::= 1*64<token-characters> ; 1-64 characters

   <error-token> ::= "X"1*63<token-characters>

                     ; 2-64 chars beginning w/X

   <integer> ::= 1*5<digit> ; 1-5 digits.

   <digit> ::= "0" | "1" ... "8" | "9" ; 0-9

   <token-characters> ::=

                  <Any of these ASCII characters: a-z, A-Z,

                   - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >

                               ; upper and lowercase a-z plus

                               ; printables minus the colon ":"

                               ; character.

   <octet-string> ::= 1*512<octet-characters>

   <octet-characters> ::=

                  <any octet from  00 to 377 (octal) except for

                   ASCII NUL (000), CR (015) and LF (012)>

Notes on Syntax:

   1)   To promote interoperability among variant

        implementations, with respect to white space the above

        syntax is understood to embody the "be conservative in

        what you send and be liberal in what you accept"

        philosophy.  Clients and servers should not generate

        unnecessary white space (space and tab characters) but

        should accept white space anywhere except within a

        token.  In parsing responses, white space may occur

        anywhere, except within a token.  Specifically, any

        amount of white space is permitted at the beginning or

        end of a line both for queries and responses.  This

        does not apply for responses that contain a user ID

        because everything after the colon after the operating

        system type until the terminating CR/LF is taken as

        part of the user ID.  The terminating CR/LF is NOT

        considered part of the user ID.

   2)   The above notwithstanding, servers should restrict the

        amount of inter-token white space they send to the

        smallest amount reasonable or useful.  Clients should

        feel free to abort a connection if they receive 1000

        characters without receiving an <EOL>.

   3)   The 512 character limit on user IDs and the 64

        character limit on tokens should be understood to mean

        as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)

        token will be defined that has a length greater than 64

        and b) a server SHOULD NOT send more than 512 octets of

        user ID and a client MUST accept at least 512 octets of

        user ID.  Because of this limitation, a server MUST

        return the most significant portion of the user ID in

        the first 512 octets.

   4)   The character sets and character set identifiers should

        map directly to those defined in or referenced by RFC 1340,

        "Assigned Numbers" or its successors.  Character set

        identifiers only apply to the user identification field

        - all other fields will be defined in and must be sent

        as US-ASCII.

   5)   Although <user-id> is defined as an <octet-string>

        above, it must follow the format and character set

        constraints implied by the <opsys-field>; see the

        discussion above.

   6)   The character set provides context for the client to

        print or store the returned user identification string.

        If the client does not recognize or implement the

        returned character set, it should handle the returned

        identification string as OCTET, but should in addition

        store or report the character set.  An OCTET string

        should be printed, stored or handled in hex notation

        (0-9a-f) in addition to any other representation the

        client implements - this provides a standard

        representation among differing implementations.

6.  Security Considerations

   The information returned by this protocol is at most as trustworthy

   as the host providing it OR the organization operating the host.  For

   example, a PC in an open lab has few if any controls on it to prevent

   a user from having this protocol return any identifier the user

   wants.  Likewise, if the host has been compromised the information

   returned may be completely erroneous and misleading.

   The Identification Protocol is not intended as an authorization or

   access control protocol.  At best, it provides some additional

   auditing information with respect to TCP connections.  At worst, it

   can provide misleading, incorrect, or maliciously incorrect

   information.

   The use of the information returned by this protocol for other than

   auditing is strongly discouraged.  Specifically, using Identification

   Protocol information to make access control decisions - either as the

   primary method (i.e., no other checks) or as an adjunct to other

   methods may result in a weakening of normal host security.

   An Identification server may reveal information about users,

   entities, objects or processes which might normally be considered

   private.  An Identification server provides service which is a rough

   analog of the CallerID services provided by some phone companies and

   many of the same privacy considerations and arguments that apply to

   the CallerID service apply to Identification.  If you wouldn't run a

   "finger" server due to privacy considerations you may not want to run

   this protocol.

7.  ACKNOWLEDGEMENTS

   Acknowledgement is given to Dan Bernstein who is primarily

   responsible for renewing interest in this protocol and for pointing

   out some annoying errors in RFC 931.

References

   [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January

       1985.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,

       USC/Information Sciences Institute, July 1992.

Author's Address

       Michael C. St. Johns

       DARPA/CSTO

       3701 N. Fairfax Dr

       Arlington, VA 22203

       Phone: (703) 696-2271

       EMail: stjohns@DARPA.MIL


Running ID with The Internet Adapter

ID uses only straight TCP connections, and should therefore work with any SLIP-emulator. I have tested it with The Internet Adapter (TIA) version 2.05, and had no problems.

But, running a server with TIA requires you to redirect a port on your providers machine to the server port on your PC. This may be an acceptable solution for e.g. FTP, where you can choose control port. For the finger and identification protocols, this is not normally possible. It doesn't make sense either. If a server somewhere wants your ID, it will request this ID from the machine you are running TIA on. And, if this is a properly set up UNIX box, get it.

If you are using TIA (or another SLIP emulator), you have already got all the advantages of an identification server.

There is no need and no use running ID with a SLIP emulator.


Changes from version 0.00 to version 0.01

This is, believe it or not, the second released version of ID. A few bugs (Ouch!) have been fixed, and some minor changes have been made.

Two of the bugs in version 0.00 were really bad, and slipped through my tests because I didn't test ID on more than two systems. Sorry. They are fixed now:

1.	If you tried to start ID version 0.00 more than once, it would give an error message and freeze your system (But not if you were running OS/2, like me...).

2.	ID wouldn't run without BWCC.DLL. Nobody reported this bug. Maybe everybody has got a copy of BWCC.DLL? Or maybe nobody realised that this was a bug. ID has never used the Borland Windows Custom Controls (BWCC.DLL), and should therefore not require this file. But my fingers (the ones attached to my hand, not the RFC ones) often run without control, and had included the library in the ID project (Ooops). Because BWCC.DLL was installed both on my home and work computer, I never noticed. Until yesterday, when I got a new computer at work. Fresh from our computer department, and of course without all the programs I had installed on the old one :-(

I have also made some small improvements, hopefully without introducing new bugs:

1.	The parsing of FINGER.TXT is changed, so you don't need to include blanks at the end of lines.

2.	Some options are added to ID.INI.

New versions of ID will be announced on my home page: <URL:http://www.sn.no/~bmork/>